There is currently a proliferation of organizational networked systems. Every type of organization, be it a commercial company, a university, a bank, a government agency or a hospital, heavily relies on one or more networks interconnecting multiple computing nodes. Failures of the networked system of an organization or even of only a portion of it might cause a significant damage, up to completely shutting down all operations. Additionally, all data of the organization exists somewhere on its networked system, including all confidential data comprising its “crown jewels” such as prices, details of customers, purchase orders, employees' salaries, technical formulas, etc. Loss of such data or leaks of such data to outside unauthorized entities might be disastrous for the organization.
As almost all organizational networks are connected to the Internet at least through one network node, they are subject to attacks by computer hackers or by hostile adversaries. Quite often the newspapers are reporting incidents in which websites crashed, sensitive data was stolen or service to customers was denied, where the failures were the results of hostile penetration into an organization's networked system.
Thus, many organizations invest a lot of efforts and costs in preventive means designed to protect their networked systems against potential threats. There are many defensive products offered in the market claiming to provide protection against one or more known modes of attack, and many organizations arm themselves to the teeth with multiple products of this kind.
However, it is difficult to tell how effective such products really are in achieving their stated goals of blocking hostile attacks, and consequently most CISO's (Computer Information Security Officers) will admit (maybe only off the record), that they don't really know how well they can withstand an attack from a given adversary. The only way to really know how strong and secure a networked system is, is by trying to attack it as a real adversary would. This is known as penetration testing (pen testing, in short), and is a very common approach that is even required by regulation in some developed countries.
Penetration testing requires highly talented people to man the testing team. Those people should be familiar with each and every known security vulnerability and attacking method and should also have a very good familiarity with networking techniques and multiple operating systems implementations. Such people are hard to find and therefore many organizations give up establishing their own penetration testing teams and resort to hiring external expert consultants for carrying out that role (or completely give up penetration testing). But external consultants are expensive and therefore are typically called in only for brief periods separated by long time intervals in which no such testing is done. This makes the penetration testing ineffective as security vulnerabilities caused by new forms of attacks that appear almost daily are discovered only months after becoming serious threats to the organization.
Additionally, even rich organizations that can afford hiring talented experts for in-house penetration testing teams do not achieve good protection. Testing for security vulnerabilities of a large networked system containing many types of computers, operating systems, network routers and other devices is both a very complex and a very tedious process. The process is prone to human errors of missing testing for certain threats or misinterpreting the damages of certain attacks. Also, because a process of full testing of a large networked system against all threats is quite long, the organization might again end with a too long discovery period after a new threat appears.
Because of the above deficiencies automated penetration testing solutions were introduced in recent years by multiple vendors. These automated solutions reduce human involvement in the penetration testing process, or at least in some of its functions.
A penetration testing process involves at least the following main functions: (i) a reconnaissance function, (ii) an attack function, and (ii) a reporting function. The process may also include additional functions, for example a cleanup function that restores the tested networked system to its original state as it was before the test. In an automated penetration testing system, at least one of the above three functions is at least partially automated, and typically two or three of them are at least partially automated.
A reconnaissance function is the function within a penetration testing system that handles the collection of data about the tested networked system. The collected data may include internal data of networks nodes, data about network traffic within the tested networked system, business intelligence data of the organization owning the tested networked system, etc. The functionality of a reconnaissance function can be implemented, for example, by software executing in a server that is not one of the network nodes of the tested networked system, where the server probes the tested networked system for the purpose of collecting data about it.
An attack function is the function within a penetration testing system that handles the determination of whether security vulnerabilities exist in the tested networked system based on data collected by the reconnaissance function. The functionality of an attack function can be implemented, for example, by software executing in a server that is not one of the nodes of the tested networked system, where the server attempts to attack the tested networked system for the purpose of verifying that it can be compromised.
A reporting function is the function within a penetration testing system that handles the reporting of results of the penetration testing system. The functionality of a reporting function may be implemented, for example, by software executing in the same server that implements the functionality of the attack function, where the server reports the findings of the attack function to an administrator or a CISO of the tested networked system.
All penetration testing systems can be characterized as doing either an “actual attack penetration testing” or as doing a “simulated penetration testing”.
An actual attack penetration testing system does its penetration testing by attempting to attack the tested networked system. Such a system accesses the tested networked system during the test and is not limiting itself to simulation or evaluation. This includes verifying that the tested networked system can be compromised by actively attempting to compromise it and then checking if it was indeed compromised. This implies that a possible side-effect of executing an actual attack penetration test might be the compromising of the tested networked system.
A simulated penetration testing system does its penetration testing while avoiding disturbance to the tested networked system and specifically while avoiding any risk of compromising it. This implies that whenever there is a need to verify that the tested networked system can be compromised by an operation or a sequence of operations, the verification is done by simulating the results of that operation or sequence of operations or by otherwise evaluating them, without taking the risk of compromising the tested networked system.
Every penetration testing system operates by iteratively (physically or simulatively) compromising network nodes of the tested networked system. At any iteration during the testing process some of the network nodes of the tested networked system are considered to be already compromised by the potential attacker, and the penetration testing system is attempting to compromise an additional network node (not yet compromised) by utilizing the already-compromised network nodes that are operating under the control of the attacker. Once an additional network node is found to be compromisable, it is added to the group of already-compromised network nodes and a new iteration of the testing begins.
As explained above, in every iteration of a penetration testing campaign there is an attempt either to compromise a network node (if the penetration testing system is of the “actual attack” type) or to determine that it is compromisable (if the penetration testing system is of the “simulation/evaluation” type).
There is, however, a difference between “compromising a network node” and “fully controlling a network node”. Similarly, there is a difference between “determining that a network node is compromisable” and “determining that a network node is fully controllable”.
A node may be compromised by tempting a user of the node to execute malicious code, as is the case when opening a Microsoft Word file containing a poisoned macro and enabling execution of macros or by tempting the user to select a poisoned link in an email. In such a case the malicious or poisoned code carries out operations determined by the attacker, such as exporting a confidential file out of the network node. However, the user that is to blame for the compromising may be a non-privileged user and not a user having administrator rights for the network node. Consequently, even if the user has access rights to some confidential files, he may not have access rights to other files in the node, such as confidential files owned by other users or confidential files owned by the operating system. Therefore, even though the network node was compromised, the attacker may not be able to fully control it. For example he may not be able to export a given confidential system file (e.g. a passwords file) that is the true goal of the attacker.
Lacking full control of a network node, that node may not be useful for the attacker as a tool for continuing the attack by compromising additional nodes in additional iterations of the penetration testing campaign. For example, having full control of a first node (including an ability to read its passwords file), the attacker could have compromised a second node in the same local sub-network by logging into the second node by mimicking a legitimate user using his user name and password. But lacking full control of the first node, the attacker cannot use such a method for compromising the second node, and therefore may have no way of compromising the second node.
A real attacker that compromises a target network node and achieves less than full control of it, will typically attempt to employ “privilege escalation” techniques. The purpose of such techniques is to “escalate” (i.e. to increase) the current access rights of a user to a higher level, hopefully to the highest level that allows full control of the node. Such techniques are well known in the art and may include retrieving a passwords file for finding user names and then intelligently guessing passwords, dumping of certain system files and then looking for credentials in the dumps, etc. Dumping a system file (e.g., a SAM file, which is a Security Account Manager file containing users' passwords) is a common way to escalate privileges. Often, it is possible to retrieve the LM hashes from a computer that may include an administrator's hash. It can also be possible to use the shadow copy feature of Microsoft Systems to get the “SYSKEY” and “SAM” files. Another approach used with Unix systems is retrieving the/etc/password file (e.g., when there is a non-chrooted FTP server), enumerating the usernames of the system and trying the usernames as the passwords for the corresponding accounts (relying on the fact that many careless users use their username as a password). Another approach is to investigate the services running in a computer and check which users are running those services. Malicious code injected in one of those processes could retrieve escalated privileges from the process owner. In some embodiments, shared folders can be useful for achieving privilege escalation, because sensitive information may be stored in those shared folders with, at most, few restrictions. Another approach for achieving privilege escalation is to utilize a combination of a DLL preloading vulnerability and having access to a widely used shared folder from which users execute certain applications. In such case, one of the legitimate DLLs can be replaced by a malicious DLL. Additional information on privilege escalation methods can be found in published International Patent Application No. WO 2008/054982, which is incorporated by reference herein in full.
However, there is no guarantee that a given attempt to achieve full control of a given network node by applying privilege escalation techniques will be successful. The result depends on many internal factors of the given network node, such as the type of the Operating System, the version of the Operating System, the strength of passwords used by the users, the encryption method used for protecting critical files, the defensive applications installed in the node, etc.
If the attempt is successful, then the targeted node is now indeed under full control of the attacker and can be used by the attacker for whatever operation that is required for continuing the attack of the networked system, including for attacking another node in the next iteration of the attack. If the attempt is unsuccessful, then the attacker may not be able to continue with his attack plan for the networked system, even though he may still use the resources of the compromised node according to the limited access rights he had achieved in it.
Penetration testing systems that use actual attacks have no difficulty in mimicking the behavior of a real attacker in this respect. When such a penetration testing system succeeds in gaining a foothold in a target network node, it may attempt to achieve privilege escalation exactly as a real attacker does. The system may employ the same techniques available to a true attacker and consequently will achieve the same results. When the attempt to achieve full control of a node fails, the campaign is unable to use to advantage (in the next iterations of the attack) any access right in the targeted node that was not actually achieved. Therefore, the conclusions reached by such penetration testing system regarding the vulnerabilities of the tested networked system will correctly reflect the vulnerabilities available to a real attacker.
But penetration testing systems that use simulation or other types of non-intrusive evaluation are not allowed to find out the ability of an attacker to achieve privilege escalation by actually attempting to achieve it. This creates a difficulty for such systems.
Prior art simulation-based penetration testing systems typically bypass the difficulty by simplifying the simulation in assuming that privilege escalation is always possible. In other words, assuming that once an attacker succeeds in compromising a node (e.g. getting the access rights of one of the authorized users of that node), it is able to eventually get full control of the node (e.g. accessing every file in the node and being able to run any desired code in the node).
Such assumption eliminates the difficulty but results in somewhat inaccurate conclusions from the testing. In the real world some nodes may not be fully controllable after being compromised to some extent. Therefore, a penetration testing campaign relying on the above simplifying assumption may incorrectly conclude that a given networked system is highly vulnerable to attacks, while in reality only some low-importance resources and assets can be compromised by an attacker.
Therefore, it is desirable to have penetration testing systems that, while being of the simulation/evaluation type, are still able to provide accurate conclusions about tested networked systems.